Techniques of transmitting multimedia content to a radiocommunication terminal are already known.
Conventionally, according to a first transmission technique, the design of a service, i.e. the offer of information to a user of a radiocommunication terminal, implements the following flow:                initial content is sent to the terminal;        the user consumes it, and makes a request;        response content is then sent to the radiocommunication terminal, etc.        
The service is therefore designed as a series of contents sent to the terminal of the user in response to interactive requests.
For example, if the user requests a weather service, the initial content sent to the terminal includes the weather forecast for the day.
The user consumes it, i.e. reads the weather forecast for the day, and makes a request to obtain the weather forecast for the following day.
New response content, comprising the weather forecast for the following day, is then sent to the radiocommunication terminal, with this new content replacing the initial content in the memory of the terminal.
According to this first transmission technique, each response content sent includes an entire scene, representative of the required content, but within the framework of the aforementioned example, only the pictograms that describe the weather to come will be modified, with the other graphics objects composing the multimedia scene of presenting weather forecasts remaining unchanged (for example the underlying map of France).
Consequently, a major disadvantage of this first technique of the prior art is that it requires the downloading of an entire scene in response to one request from the user, even if there are only a few modifications between the initial content and the response content.
Downloading the response content therefore corresponds at least partially to wasted time, which is costly in terms of transmission resources, all the more so that interactive multimedia services for radiocommunication terminals have the lowest bandwidth for mobile networks (about a dozen kilobits per second), and suffer from the “interactive” example of high-speed Internet.
In addition, the fact of loading a new scene introduces a rupture for the user: any context of local interaction is therefore lost, as well as any usage preferences. Indeed, according to this technique of prior art, the initial content is fully replaced by new content.
Consequently, when a communication session is broken and then followed by a reestablishment of the session, it may be necessary to load the initial content again for example in order to retrieve the usage preferences of the user.
There are moreover other techniques for transmitting multimedia content to a radiocommunication terminal.
As such, according to a second technique, scene commands make it possible to create scenes which are then sent progressively to the radiocommunication terminal.
Such commands are in particular defined in the BIFS and LASeR descriptive formats (“Lightweight Application Scene Representation”), such as defined in ISO/IEC 14496-20:2006, published in 2006, of which a temporary version is available under reference MPEG N7480: “Study Text of ISO/IEC 14496-20/FCD”.
These scene commands thus make it possible to start to play a scene before it is completely downloaded, if the commands are sent in increasing temporal order.
However, a disadvantage of this second technique is that it also requires the full loading of an entire scene in response to user interaction, even if according to this technique the radiocommunication terminal can begin to play the scene while it is being downloaded.
In addition, as shown in relation with FIG. 2A, the initial scene 211 restored by the terminal is replaced, as the multimedia content is transmitted, with a first updated scene 221, then a second updated scene 231, then a third updated scene 241 . . . . The terminal thus loses knowledge of the initial scene, since the last scene memorized in the terminal corresponds to the last updated scene (for example, the third updated scene 241).
As such, a major disadvantage of this technique is that in the event the transmission is interrupted and then re-established, the terminal must load the initial scene again, especially if the user wishes to retrieve his preferences and/or any context of local interaction.
Finally, a third known technique in transmitting multimedia content to a radiocommunication terminal is shown.
According to this technique, the media player (radiocommunication terminal) has a programming language interpreter, for example of the ECMAScript or Java (registered trademarks) type. The scene includes a complex script that connects to a server, implements a data exchange protocol with the server (parsing of an XML document if the data exchanged with the server is in XML format, for example) and builds the elements of the scene according to the data received.
This third technique reverts to implementing the equivalent of scene commands within the very script of the scene itself.
However, this technique does not apply to current mobile terminals, since very few terminals have the environment, resources or performance that are required to implement it.
In addition, a major disadvantage of this technique is that it generates a high implementation cost, and in light of current resources, it can only be applied to simple scenes, comprising simple graphics objects that have little movement.
Other disadvantages of this technique of the prior art reside furthermore in the size of the content, the complexity in creating content, and the interdependency between the content and the servers implementing the same variant of the data exchange protocol.
Indeed, content containing a processing script of the data exchange protocol with the server has a minimal size (excluding the scene properly speaking) of approximately 1000 to 40,000 octets. The variability in the size of the script comes in particular from the possibility of implementing protocols of the “XML” type, more voluminous in terms of size, or binary, which are less voluminous, and of providing protocols that are more or less complete in terms of the number of possible scene modification commands.
As such, the degree of complexity in creating content according to this technique of the prior art is higher than that for simple “passive” content, i.e. without a script.
Finally, another disadvantage of this third technique is that in order to be able to server data to such content, the server has to implement the data exchange protocol used by the content that it has to serve. The server must therefore where applicable be modified or replaced with another server, in order to be adapted to content using another data exchange protocol.